Splunk Security Essentials でセキュリティのログ分析のベストプラクティスを知る

セキュリティ強化のためのログ分析をするうえで、どのログを取得するべきか、何から始めたらいいのか、どんな脅威から守る必要があり、どうやってログを分析すればいいのか、ログ活用をする上で非常に重要なポイントになってきます。

ログ活用のユースケースを増やして自分たちのセキュリティレベルを高めていくには、こういったセキュリティのナレッジが必要になってきます。

Splunkはあらゆるログを扱い分析するための統合ログ分析プラットフォームですが、Splunkには多くのユースケースとセキュリティナレッジが蓄積されている点も大きな特徴です。
Splunk Security Essentials（SSE）は、これらのユースケースとセキュリティナレッジを自分たちが持つログソースやビジネスとのマッピングを実現し、ログ活用を促進するための無料の App です。

Splunk Security Essentials では事前構築されたセキュリティユースケースと検索クエリを、App 内で検索することができます。
例えば、セキュリティフレームワークを起点にベストプラクティスは何かを学習し、実装していくためにはどのデータを取得するべきか、データ取得のためのガイダンスを知ることができます。
また、取り込んだデータから利用できるセキュリティユースケースを調べ、アラート・調査・ダッシュボード・レポーティングなどの目的に応じたログ分析を実現することができます。

Splunk Security Essentialsをインストールする

Splunkのコンソールにログインして、App を検索してインストールするだけです。

https://docs.splunk.com/Documentation/SSE/3.8.0/Install/InstallSSE

https://splunkbase.splunk.com/app/3435

どのログを取得するべきなのかを知る

インストールした後、Apps から Splunk Security Essentials にアクセスします。

最初にどのログを取得するべきなのかを知ります。
Data > Security Data Journey にアクセスしてみます。

セキュリティを強化していくためにデータの有効活用をどのように行っていけばいいのか、６つの段階に分けてポイントを示してくれます。

それぞれのステージをクリックすると、詳細が出てきますので各ステージの説明やマイルストーンを確認することができます。
簡単に要点だけ以下にまとめました。
このようにレベルに合わせて取り組む内容のブループリントとして参考にすることができます。

ステージ	概要
1. Collection	セキュリティインフラの基礎となる重要なデータを取り込みます
2. Normalization	CIMなどのデータ正規化を行い、相関分析など広範囲なログの分析が行えるようにします
3. Expansion	脅威ハンティングを行うために、よりコンテキストの高いログを収集します
4. Enrichment	脅威インテリジェンスを取り込み、ログ分析に活用します
5. Automatic and Orchestration	アラート、トリアージ、脅威への対応を強化するための継続的なセキュリティのモニタリングを行います
6. Advanced Detection	機械学習をチューニングして、異常な行動分析、未知の脅威に対して能動的な検知を行います

ページを少し下にスライドすると、ステージ１，２，３では、収集すべきデータの例が記載されるので何のデータを優先的に取得するべきか参考にしていただくことができます。

ステージ１，２，３で推奨されているデータソースを以下にまとめました。

ステージ１

種別	データソース
ネットワーク	ファイアウォールログ（Paloalto, Cisco, Checkpoint, Fortinetなど）
エンドポイント	OSログ（Windowsイベントログ, Linuxシステムログ, Linux監査ログ, Macシステムログ）
認証	Windows AD, IAM
Webアクティビティ	NGFW（Paloalto, Cisco, Checkpoint, Fortinetなど）, ウェブプロキシ（Bluecoat, Zscaler, Cloudflare Zero Trustなど）

ステージ２

種別	データソース
資産データ	Active Directory, LDAP, IAM/SSO, ITSM

ステージ３

種別	データソース
ネットワーク	プロトコル固有のWire data（DNS、DHCP）
エンドポイント	プロセス操作などのOS詳細イベントログ（Sysmon, OSQuery, EDR Event Logs）

ステージ４，５，６はデータソースではなく、活用方法に焦点が当てられています。

何から始めればよいかを知る

次に、分析する上で何から始めればよいかを知ります。
Analytics Advisor の MITRE ATT&CK Framework に遷移してみます。

MITRE ATT&CK は国際的に利用されているセキュリティフレームワークの一つで、攻撃者視点で攻撃の目的と攻撃手法をまとめたものです。
攻撃の目的と手法は TTP（Tactics=戦術, Techniques=技術, Procedures=手段）と呼ばれるセットで、攻撃（脅威）を検索できるようになっています。
概要については事前に知っている前提で話を進めていきますが、MITRE ATT&CK を初めて聞いたよ、という方は下記ページがフレームワークを紹介している本家のページになるので参考にしてみてください。

https://attack.mitre.org/

Splunk Security Essentials に戻って、こちらでは MITRE ATT&CK の TTP に対して、どのログソースで何の分析を行えば脅威検出できるかをガイドしてくれます。

今取り込んでいるデータに対して、いくつのコンテンツ（分析ユースケース）が既に適応できているか／適応することができるかを教えてくれています。
「コンテンツ」が Splunk Security Essentials に事前に取り込まれているので、利用用途に沿って検索することで、分析が始められる仕組みになっています。

少しページをスクロールダウンすると、MITRE ATT&CK Matrix（TacticsとTechniques/Sub techniquesの一覧表）上で、セキュリティ検知のためのユースケースが何件存在しているかを表示することができます。
またこちらには、各種フィルターがついていて、色々な観点でどんなコンテンツが該当するかを一目で見ることができます。

MITRE ATT&CKを利用する上で、TTP が多すぎて何から手を付ければいいのか、何が自分たちにとってクリティカルな脅威なのかが分からず、始められないというケースも多いのかなと思います。
MITRE ATT&CKには攻撃アクターという、犯罪組織グループ単位でどんな業種の企業を対象にどのような攻撃をよく仕掛けてくるのかがまとめられています。
（↓本家ページ参考です。）

https://attack.mitre.org/groups/

ここで自分の業種がどの犯罪組織グループから狙われていて、どんな脅威に対する対策を優先すればいいのかを知ることが有効的です。
そんな時、お勧めな使い方として、「MITRE ATT&CK Threat Group」で自分の業種でフィルターをかけ、自分たちの業種をターゲットにする犯罪組織グループが攻撃手法として利用する脅威に絞ってログ分析ができるようにします。本家のMITRE ATT&CKのWebページでは業種起点での検索ができないので、非常に役に立ちます。

試しにここでは、小売業 Retail でフィルタリングしました。
マトリックスの中に下に赤い線が入っているものが、フィルタリングした業種を対象とする攻撃グループが存在するテクニックになります。
さらに「||」記号をクリックすると、サブテクニックの表示が可能です。

テクニックをクリックして（クリックすると画面下部のパネルのフィルタにテクニックが入力されます）、画面
をスクロールするとそのテクニックに有効なコンテンツ（分析ユースケース）がいくつ適応されているか／適応可能かを見ることができます。
この例だと、Account Manipulation のテクニックを検知するコンテンツを見つけていきます。

さらに、そのパネルのタブを切り替えて、Selection by Data Source を見れば、どのデータソースを取り込むことで、コンテンツを適応させることができるかを見れます。
この例だと、EDR、Azure、Change Events Data、Windows Security、AWSのデータソースが対象となることが分かります。

この中で「AWS」のデータソースに絞って対応を行うことを検討します。
さらにまだ実装されていないコンテンツ（Available）で絞ります。
またパネルのタブを Content list に切り替え、コンテンツを確認します。

「AWS IAM Failure Group Deletion」と「AWS IAM Successful Group Deletion」が見つかります。
少しスクロースダウンすると、見つかったコンテンツをブックマークに追加することができるので追加します。（この他にも、データ入力待ちや実装済みなどに設定することもでき、コンテンツの実装状況を管理することができます。）
ただ、本来ここでブックマーク登録されると思ったのですが、登録処理がずっと終わらず登録できませんでした。今回試している環境がデモ環境だからかもしれません。

さらにスクロールダウンすると、絞り込んだコンテンツの詳細を見るために、ドリルダウンボタンがあるので、クリックします。

フィルターが入力された状態で Content の Security Content に遷移されます。
ステージ１の「Multiple Account Deletion by an Administrator」をクリックして、詳細を確認してみます。

コンテンツの内容を確認していきます。
内容自体は英語で書かれていますが、そのまま読むか、Google翻訳でページを訳すなどして確認していきます。

詳細
Detect multiple accounts being deleted by an Administrator
(意訳) 管理者によって削除された複数のアカウントを検出する

Security Impact
A technique used by attackers is to create multiple accounts, take a series of actions, and then delete the accounts to mask the activity. This search will find the account which has been used to deleted said accounts.
(意訳) 攻撃者が使用する手法は、複数のアカウントを作成し、一連のアクションを実行した後、アカウントを削除してアクティビティを隠すことです。この検索により、削除されたアカウントに使用されたアカウントが見つかります。

また、Data Availability の「Available」をクリックしてみると、ポップアップが表示されこのコンテンツのデータソースを確認することができます。
CloudTrailのデータソースが該当していて、既に取得できていることが分かります。

コンテンツの画面に戻って、少しスクロールダウンすると、データモデルが利用でき、高速化されているため、分析クエリが使える状態になっていることが分かります。
ここでコンテンツが正しく使えるよう前設定ができているかどうかを確認することができます。
実際の分析クエリの内容も確認することができます。
SplunkではCIM（Common Information Model）というログ正規化のフォーマットを採用しており、正規化することで異なるベンダー機器（システム）からのログを横断的に分析できる仕組みになっています。
このデータモデルには、CloudTrailのログも該当しており、以下の分析クエリでIAMユーザーまたはグループが削除されたイベントを抽出します。

CIMについての概要を知りたくなった時は以下のブログも参考にしてみてください。

https://dev.classmethod.jp/articles/splunk-cim-sakuma-20240322/

さらにこのコンテンツを使って検知があった時の対処方法についても確認してみます。
さらにスクロールダウンして、How To Respond を展開します。

When this search returns values, initiate your incident response process and capture the time of the creation and deletion events, as well as the user accounts that created the account and the account name itself, the system that initiated the request and other pertinent information. Contact the account owners, to verify whether or not this is authorized behavior. If not, begin to investigate actions taken by each account leading up to it’s deletion. If it is authorized behavior, document that this is authorized and by whom.
(意訳) この検索で値が返された場合は、インシデント対応プロセスを開始し、作成イベントと削除イベントの時刻、アカウントを作成したユーザー アカウントとアカウント名そのもの、リクエストを開始したシステム、その他の関連情報をキャプチャします。アカウント所有者に問い合わせて、これが許可された行為であるかどうかを確認してください。そうでない場合は、削除に至るまでに各アカウントが行ったアクションの調査を開始します。それが許可された行為である場合は、これが誰によって許可されているかを文書化してください。

後は、さらにスクロールダウンして、アラートとして設定したり、既存のダッシュボードに追加を行い分析できる環境に止めておきます。

こんな感じでコンテンツを探したり、セキュリティフレームワークの脅威からどこまでをカバーできているかをチェックしながらセキュリティを実装していくことができます。

まとめ

ログユースケースの開発や活用もある一定のところまでいくと中々進みづらい状況になることも多いかと思いますが
セキュリティフレームワークで全体を見ながらセキュリティ強化できるので非常に良いソリューションですね。